An enterprise may store and process information using “business objects.” As used herein, the phrase “business object” may refer to, for example, a software entity representing real-world items used during the transaction of business. For example, a business object may represent a business document such as a sales order, a purchase order, or an invoice. Note that one business object may receive information from (or provide information to) other business objects. For example, when an “order quantity” in a purchase order business object is modified, an “amount due” in an associated invoice business object may be automatically updated.
A business object may be stored in a storage device, such as by storing information in a database table on a hard disk drive. At times, the business object may be loaded into memory (e.g., server memory) and manipulated as appropriate by a processor. When finished, the processor may store the updated business object back into the storage device using a “database commit.” Note that a single business object may potentially be updated by more than one other business object. As a result, updates to a business object may need to be managed and/or coordinated. That is, when a business object is being used and/or modified during a transaction, it may be important to prevent other business objects from accessing or modifying that business object until the transaction is complete.
To facilitate such coordination, a business object may be “locked” to prevent other business objects from accessing or modifying that business object while it is being updated (or potentially updated). In this way, information associated with the locked business object can be updated without interference from other business objects. Note that locking too many business objects (and/or for too long a period of time relative to the transaction) may unnecessarily prevent that business object from being used degrade the performance of the system. Locking too few business objects (and/or for too short a period of time relative to the transaction) may result in errors when a business object is simultaneously accessed by multiple parties. Moreover, the processing time and logic required to track the lock/unlock status associated multiple business objects can be substantial and difficult to program. This may be especially true when hundreds of business objects need to be considered.
Accordingly, systems and methods to automatically and efficiently handle how locks are placed on and/or removed from business objects may be provided in association with some embodiments described herein.